Currently an increasing number of video streaming techniques make use of so-called content segmentation wherein content data, e.g. video data, are logically or virtually split into several segment files or streams, thus generating segmented content. A segment file may relate to a file comprising content data, which may be retrieved by a file retrieval protocol, e.g. HTTP or FTP. Similarly, a segment stream may relate to a stream comprising content data which may be retrieved by a streaming protocol, e.g. RTSP/RTP or HAS. Segment files or streams (hereafter in short also referred to as segments) can be delivered to a client separately, but when recombined at the client they provide a seamless video stream.
During the content segmentation process a so-called manifest file is generated that identifies segments and describes the relation between the different segments and the location(s) where the segments may be retrieved. Segmented content can be provided in several representations, e.g. alternative versions of the same content that differ for example in resolution, the number of audio channels and/or a different bitrate. All representations are temporally aligned such that segments of different representations can be interchanged seamlessly. Streaming of segmented content in different representations is referred to as adaptive streaming wherein an adaptive streaming protocol such as HTTP adaptive streaming (HAS) and related protocols may be used.
HAS enables the delivery of (live) video by means of the HTTP protocol, by transmitting the video in segments that are independently requested by the client from a web server. Various commercial and standardized HAS protocols exist, such as Apple HTTP Live Streaming http://tools.ietf.org/html/draft-pantos-http-live-streaming-07, Microsoft Smooth Streaming http://www.iis.net/download/ SmoothStreaming, Adobe HTTP Dynamic Streaming http://www.adobe.com/products/ httpdynamicstreaming, 3GPP-DASH TS 26.247 Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP] and MPEG Dynamic Adaptive Streaming over HTTP MPEG DASH ISO/IEC 23001-6).
Segmented content may be used to dynamically adapt to changing bandwidth requirements, e.g. by switching from a high to a low quality video stream. Moreover, segmented content may also allow for discriminating between popular and less popular (video) segments. For example, typically content associated with the beginning of a video (such as trailers) will be watched more often (and thus more popular) than content at the end. Similarly for some use cases, low-bitrate lower-quality video content (e.g. the lowest resolution HAS segments) will likely be downloaded more frequently than high quality content (e.g. higher-resolution HAS segments), which may be more expense or demands more from the receiving device or requires more bandwidth. The above-mentioned properties of segmented content may be advantageously used by a content delivery network (CDN), which is configured to deliver content to a consumer. A CDN may for example store popular, more frequently requested content segments at multiple delivery nodes in the CDN so that bandwidth problems may be reduced and efficient delivery is guaranteed. A CDN control function (CDNCF) may centrally manage the locations within the CDN, hereafter referred to as delivery nodes, where content segments associated with a content item (such as a video or movie) may be retrieved (get).
Although a lot of different streaming protocols, such as RTP/RTSP or RTMP, may be used for implementing streaming of (segmented) content to a client, HTTP or HTTP-based streaming protocols are the most widely used within a CDN. These streaming protocols use standard HTTP—a stateless, client-server protocol—to request and receive content segments from a server not requiring new functionality and allowing for segments to be cached transparently. Moreover, unlike most other streaming solutions, HTTP traffic as such is usually not automatically blocked by firewalls or network address translators (NATs).
Moreover, HTTP-based streaming is not session-based. This means that the HTTP server does not need to maintain sessions for the various clients it is serving. This way the HTTP server architecture can be kept simple. However, this session-less nature combined with the fact that HTTP is a client-initiated protocol also means that an HTTP server, e.g. a delivery node in a CDN, is not able to initiate communication with a client.
In order to enable a client to access (download/retrieve) segments stored in a CDN, the client is provided with a so-called manifest file comprising a list of segments each being identified by a segment identifier (e.g. a segment file name) and segment locations (segment locators), e.g. URLs, pointing to a network node where the segments may be accessed (retrieved). Depending on the particular CDN and/or implementation, a pre-defined manifest file may be stored on one or more (delivery) nodes of the CDN, together with the associated segments, or a manifest file may be dynamically generated by the CDN upon user request.
This way, when a consumer (client device) requests a particular segmented content item (such as a video), the CDN may, on request, identify a manifest file stored on a (delivery) node that is suitable for enabling the delivery of the requested content item to the customer (device). Alternatively, the CDN may generate a new manifest file identifying one or more delivery nodes which, taken together, are suitable for delivering the requested content segments to the customer. Subsequently the CDN may send the generated manifest file in a response to the requesting client (device) of the consumer.
During streaming of the content segments, the network configuration or load distribution in the CDN may change. For example, a failure or overload in a node of a CDN may result in a situation wherein one or more delivery nodes in a CDN are no longer able to deliver content segments identified in the manifest file. Also in other situations, e.g. in an impending overload situation, it may be required to prevent an overload situation by transferring the task of delivering a particular content segment to a particular consumer (content receiving device) during the streaming process from one delivery node to another delivery node of the CDN or even to a delivery node in another CDN. One can even imagine that when a client device of a particular consumer changes its position, it may also be more advantageous to have another delivery node, now being the more closer one, take-over the streaming from the original node. Other events in the delivery network that may require or warrant a change in the delivery of segments to a client (i.e. trigger load balancing mechanisms in the network) are planned outages, a Server Migration, a CDN Migration and so on.
In known methods such change in the delivery of segments to a client may be realized in several ways. In some cases a CDN may use for example an HTTP redirect scheme in order to redirect the request for a segment to the desired delivery node. Such scheme however may require and trigger a separate redirect response message (simply referred to as a redirect) for every segment the client will request in the future, or even multiple redirect response messages per requested segment, thereby introducing a substantial increase of the signalling load in the network. This is especially relevant in the case when a large amount of consumers is dependent on the same delivery node and is simultaneously requesting and retrieving the same content. Not only may the additional signalling load flood parts or all of the CDN, the redirects may cause unacceptable service interruptions at the client-side, since the delivery of the individual content segments is suddenly delayed as a result of the redirects. Hence the redirect scheme may not be able to effectively prevent service interruptions due to changes in the network configuration (as a result of for instance a delivery node failure). The service interruptions may be more pronounced, in situations were for example little content is buffered at the client device, in situations were multiple redirects occur, or were the new target delivery node is located at a considerable larger distance to the client device, compared to the previous one.
Alternatively, the CDN may generate a newly updated manifest file for the client on the basis of the new network configuration. However due to its very nature, the HTTP protocol does not allow the server-side (e.g. the CDN) to directly and or pro-actively initiate the transmission of such newly updated manifest file to the client or, alternatively, initiate a client request for such a newly updated manifest file. Whether the client receives an updated manifest file or not is completely dependent on the initiative of the client (which however is not aware of (pending) changes in the network configuration) to request such update. Likewise, if for example a segmented content stream would be made available by the CDN in a higher representation than present in the manifest file previously provided to the client, the client has no way of knowing this and cannot profit from such higher quality stream. Even if the client would be configured to e.g. periodically request manifest file updates, such update schemes cannot effectively (quickly) an on ad-hoc basis react to changes in the network configuration and avoid service interruptions due to such changes. It would be merely coincidental if such update frequency would precisely coincide with a suddenly needed configuration change. Furthermore, implementing a very high update frequency, (which makes use of a HTTP based request-response signalling mechanism), has the disadvantage of causing a considerable overhead signalling load in the network and processor load on the client and network side, even during periods that no configuration changes (e.g. changes in the delivery of segmented content to a client) are needed or recommendable.
Hence, there is a need in the art for methods and systems, which enable improved control of streaming content to a client.